home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930276.txt < prev    next >
Internet Message Format  |  1994-06-04  |  6KB
  1. Date: Sun, 24 Oct 93 04:30:01 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #276
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sun, 24 Oct 93       Volume 93 : Issue  276
  11.  
  12. Today's Topics:
  13.                           Network Standards
  14.            slip/ppp problems in ka9q nos 930622?  (2 msgs)
  15.  
  16. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  17. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  18. Problems you can't solve otherwise to brian@ucsd.edu.
  19.  
  20. Archives of past issues of the TCP-Group Digest are available
  21. (by FTP only) from UCSD.Edu in directory "mailarchives".
  22.  
  23. We trust that readers are intelligent enough to realize that all text
  24. herein consists of personal comments and does not represent the official
  25. policies or positions of any party.  Your mileage may vary.  So there.
  26. ----------------------------------------------------------------------
  27.  
  28. Date: Sat, 23 Oct 93 02:13:51 UTC
  29. From: vk4grl@vk4grl.clayfield.ampr.org
  30. Subject: Network Standards
  31. To: tcp-group@UCSD.EDU
  32.  
  33. I guess the debate over connection oriented/connectionless services will
  34. continue for some time, however the important thing to consider is the use
  35. of appropriate protocols at each layer.  Have you ever tried to use AX25
  36. vc mode (connection oriented link layer) with NOS?  Everything goes fine 
  37. until the frequency starts to get busy.  Then AX25 retransmits and TCP
  38. retransmits and the same information is sent many many times unnecessarily
  39. It is interesting to use ISO terminology here - TCP is analogous to TP4
  40. transport which is designed for a class C network layer (unreliable) network layer.
  41. This is why when we add some lower layer error recovery things go haywire.
  42. By adding vc mode we have (sort of) turned our network layer into a class B
  43. (reliable with signalled errors) and the recovery processes used by TCP and
  44. TP4 are inappropriate.
  45.  
  46. As an example of more appropriate use of connection oriented network service,
  47. see ISO TP3 which was designed for a class B network layer.  No transport
  48. error recovery is necessary unless the network layer signals an error such
  49. as a reset or disconnect.
  50.  
  51. Should we be looking at a way of using OSI protocols on radio LAN's?  The
  52. main problem would be the protocol conversion at internet gateways.
  53.  
  54. Graham
  55.  
  56. ------------------------------
  57.  
  58. Date: Fri, 22 Oct 1993 17:20:58 -0400 (EDT)
  59. From: MIKEBW@ids.net (Mike Bilow)
  60. Subject: slip/ppp problems in ka9q nos 930622? 
  61. To: bsa@kf8nh.wariat.org, tcp-group@UCSD.EDU
  62.  
  63. I don't know of any disk corruption resulting from QEMM in Stealth Mode P,
  64. but that's in the nature of undocumented features.  The problem with hard
  65. drive corruption and QEMM Stealth is almost always traced back to disk
  66. cache software which has a faulty implementation of the virtual hard drive
  67. interface definition.  This may be exaggerated in Mode P for some reason,
  68. but I don't know.  Floppy disk access speed under DESQview usually will
  69. improve enormously under Mode P.  Also remember that I was specifically
  70. recommending use of Mode P only in connection with LOCKDMA.  Anything that
  71. happens with an undocumented feature is, by definition, risky.
  72.  
  73. As for Quarterdeck's official position on Mode P, I don't know of any
  74. statement that they have been willing to make on it at all, other than
  75. to say that it is undocumented and unsupported.  If they went so far as
  76. to warn of a specific problem such as disk corruption, that is very new.
  77.  
  78. -- Mike
  79.  
  80. ------------------------------
  81.  
  82. Date: Fri, 22 Oct 1993 18:21:53 -0400
  83. From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
  84. Subject: slip/ppp problems in ka9q nos 930622? 
  85. To: tcp-group@UCSD.EDU
  86.  
  87. In your message of Fri, 22 Oct 1993 17:20:58 EDT, you write:
  88. +---------------
  89. | I don't know of any disk corruption resulting from QEMM in Stealth Mode P,
  90. | but that's in the nature of undocumented features.  The problem with hard
  91. | drive corruption and QEMM Stealth is almost always traced back to disk
  92. | cache software which has a faulty implementation of the virtual hard drive
  93. | interface definition.  This may be exaggerated in Mode P for some reason,
  94. | but I don't know.  Floppy disk access speed under DESQview usually will
  95. +---------------
  96.  
  97. I believe the concern was that some disk controllers get confused by it and
  98. screw up their writes badly.  It may also affect the timing.
  99.  
  100. +---------------
  101. | As for Quarterdeck's official position on Mode P, I don't know of any
  102. | statement that they have been willing to make on it at all, other than
  103. +---------------
  104.  
  105. About this time last year someone on the Quarterdeck BBS (I think it was
  106. there) suggested using ST:P if ST:M and/or ST:F didn't work.  Quarterdeck's
  107. response said that yes, mode P exists, and it can work when F and M don't,
  108. but it could also do Bad Things to the disk controller and result in a low-
  109. level format being needed.  Since I've seen other kinds of problems cause
  110. this (had to low-level the drive on my former 8088 system once because
  111. something dicked with the interrupts and other parameters and the MFM
  112. controller blew up) I'm not too surprised by this.  That was the only mention
  113. of it.
  114.  
  115. ...actually, I think it may have shown up later in a tech note, but it's been
  116. almost a year since I checked because I switched to Linux :-)
  117.  
  118. ++Brandon
  119. --
  120. Brandon S. Allbery    kf8nh@kf8nh.ampr.org   bsa@kf8nh.wariat.org
  121. "MSDOS didn't get as bad as it is overnight -- it took over ten years
  122. of careful development."  ---dmeggins@aix1.uottawa.ca
  123.  
  124. ------------------------------
  125.  
  126. Date: Fri, 22 Oct 93 23:12:39 +0100
  127. From: sinanis@sungraz.cern.ch (Nick J. Sinanis)
  128. To: tcp-group@UCSD.EDU
  129.  
  130. info
  131.  
  132. ------------------------------
  133.  
  134. End of TCP-Group Digest V93 #276
  135. ******************************
  136. ******************************
  137.